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1.0  EXECUTIVE  SUMMARY 


1 . 1  INTEGRATED  DEFENSE  SYSTEMS 

An  Integrated  Defense  System  (IDS)  provides  a  coupled  suite  of  sensors, 
countermeasures  (CM’s)  and  countermeasure  empl05mient  rules  that  work  to  automatically  (or 
semi-automaticaUy)  protect  military  vehicles  from  Incoming  projectiles.  At  the  present  time, 
most  IDS  systems  are  in  research  or  developmental  stages:  thus,  there  has  been  little 
experience  with  such  systems  m  the  field.  MultiSIM-IDS  provides  the  capability  to  explore  the 
value  of  various  IDS  system  components  in  simulation  before  these  systems  are  placed  in  the 
field.  It  also  provides  an  ability  to  develop  operational  tactics  in  parallel  with  the  hardware 
system  development  through  the  use  of  simulation.  IDS  systems  are  also  called  Hit  Avoidance 
(HA)  systems  or  Defensive  Aide  Suites  (DAS).  Figure  1  illustrates  the  functioning  of  a  generic 
IDS  system. 


Figure  1 .  Functional  description  of  an  IDS  system. 


In  this  project  we  have  developed  a  simulation  specifically  tailored  to  simulate  IDS 
systems  for  ground  vehicles:  however,  similar  defensive  systems  exist  for  fixed  wing  and  rotaiy 
wing  aircraft.  IDS  systems  can  include  various  sensor  types  (launch,  tracker  or  laser 
warning),  various  countermeasures  types  (smoke,  EO  missile  countermeasure  devices,  laser 
decoy  devices  or  active  protection  systems)  and  CM  prioritization  logic.  A  simple  IDS  system 
may  consist  of  just  a  missile  launch  detector  and  smoke.  A  more  complex  system  could 
include  aU  three  sensor  types  and  multiple  kinds  of  countermeasures.  An  IDS  system  may 
also  Include  crew  warnings,  crew  tactical  reactions  to  threats,  and  crew  control  or 
prioritization  of  CM’s.  Only  simple  IDS  systems  (or  Individual  warning  sensors  or  CM’s)  have 
currently  been  deployed  on  ground  vehicles.  More  complex  systems  are  being  designed  and 
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evaluated  for  future  vehicles.  MultiSIM-lDS  provides  an  important  tool  to  design  and  evaluate 
future  systems. 

1.2  MultiSm-IDS  SIMULATION 

The  Integrated  Defense  System  (IDS)  simulation  is  the  second  DIS-based  simulation 
developed  by  OptMetrics  using  the  MultiSIM  software  development  architecture.  A  main 
feature  of  the  MultiSIM  architecture  is  development  of  the  simulation  using  a  reusable  set  of 
C++  modules  that  are  connected  together  to  form  the  complete  simulation.  Once  these 
modules  have  been  developed,  a  text-based  “connections  file”  defines  the  paths  by  which 
Information  flows  between  the  various  modules.  There  are  a  number  of  advantages  of  software 
development  Avith  this  design  including: 

■  Facilitation  of  software  reuse. 

■  Enforcement  of  modular  code  development. 

■  Ease  of  debugging. 

In  fact,  about  30%  of  the  modules  included  in  the  MultiSIM-IDS  simulation  were 
developed  on  an  earlier  program.  The  initial  version  of  MultiSIM-lDS  was  completed  in  less 
than  three  months  following  completion  of  the  software  design. 

The  MultiSIM  architecture  also  provides  advantages  in  the  use  of  the  complete  code: 

■  An  explicit,  user  understandable,  representation  of  how  data  fiows  through 
the  various  code  modules. 

■  The  ability  to  reconfigure  the  software  without  rewriting  or  even 
recompilation  of  the  soiu-ce  code. 

The  latter  feature  allowed  MultiSIM-IDS  to  simulate  the  defense  of  four  manned 
simulators  and  ten  ModSAF  vehicles,  using  a  single  SGI  workstation,  by  configuration  of  the 
same  modules  developed  to  simulate  the  defense  of  a  single  vehicle. 

1.3  APPLICATIONS  OF  MiiItiSIM-IDS 

During  a  DIS  exercise,  the  IDS  capabilities  can  be  assigned  to  selected  battlefield 
entities  (i.e.,  M1A2  tanks)  and  the  simulation  wlU  “defend”  those  entities  from  specified  types 
of  threat  munitions.  The  simulation  can  also  provide  warnings  and  situational  awareness 
Information  for  the  crews  of  manned  simulators.  An  initial  version  of  the  MultiSIM-IDS 
simulation  was  used  in  the  Force  Protection  Experiment  in  at  the  Mounted  Maneuver  Battle 
Lab. 

'  Smith,  F.G.,  G.  H.  Lindquist,  and  J.  I.  Montgomery,  "MultiSIM-DIS  Model  for  SIGINT  Sensor 
Simulation  in  DIS,"  13th  Workshop  on  Standard  for  the  Interoperability  of  Distribiited 
Simulations,  October,  1995. 
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For  the  future,  MultlSIM-IDS  provides  a  platform  for  detailed  simulation  of  the 
components  of  IDS  systems,  or  indeed  many  tj^^es  of  sensor  systems.  Higher  fidelity  models 
of  sensors,  countermeasures  or  the  threat  resolution  logic  could  easily  be  added  to  the  current 
simulation.  The  extension  of  MultiSIM-IDS  to  simulate  a  Distrlbuted-IDS  system  has  also 
been  proposed. 
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2.0  MULTISIM-roS  SIMULATION  FUNCTIONAL  DESCRIPTION 


MultiSIM-IDS  includes  modules  that  simiilate  various  types  of  sensors, 
countermeasures  and  response  logic.  The  modules  are  generic  hi  the  sense  that  parameter 
inputs  determine  the  effective  ranges  of  the  sensors,  the  effectiveness  of  the  countermeasures, 
angular  coverage  and  other  similar  system  properties.  A  Threat  Resolution  module  is  also 
included  that  provides  for  a  fixed  prioritization  of  the  countermeasures  and  for  the  effective 
use  of  the  available  countermeasures  to  defeat  various  types  of  threats.  Figure  2  provides  an 
overview  of  the  various  components  of  the  MultiSlM-lDS  simulation. 


Figure  2.  IDS  simulated  components  and  process. 


The  functioning  of  the  various  component  modules  is  determined  by  parameters  specified  in 

input  files  (.tnlt  files)  read  at  execution  time.  Those  parameters  are  described  in  the  MultlSIM- 
2 

IDS  User’s  Manual.  The  following  paragraphs  summarize  the  algorithms  used  in  the  various 
modules  of  the  simulation. 


2.1  SENSORS 

MultiSIM-IDS  includes  modules  to  simulate  the  performance  of  three  classes  of 
sensors:  launch/flash  sensors,  tracking  sensors  and  laser  warning  sensors.  All  sensors  utilize 
DIS  entity  state  information  to  determine  in  real-time  the  location  of  the  sensors  and  the 
threats.  Threat  visibility  also  considers  llne-of-sight  blockage  by  terrain.  Atmospheric  effects 
are  not  explicitly  considered  in  the  simulation.  If  atmospheric  effects  are  important  for  a 


"Smith,  F.G.,  A.W.  Dxmstan,  G.  H.  Lindquist,  MidtiSIM-IDS  HA-DIS  User’s  Manual  OMI-585, 
OptlMetrics,  Inc.,  January  1997. 
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particular  scenario,  that  can  be  represented  as  a  degraded  detection  range  for  the  affected 
sensor  types. 

A  Flash  Sensor  module  simulates  the  IR/ optical  observation  of  the  launch  flash  of  a 
missile  or  muzzle  flash  of  a  main  gun  firing.  Since  the  flash  observed  is  a  nearly 
Instantaneous  event,  no  projectile  tracking  information  can  be  obtained  from  the  flash 
sensors.  However,  munition  classification  Information  may  be  available  from  the  spatial, 
spectral  and  temporal  characteristics  of  the  flash  event.  The  MultiSlM-lDS  sensor  module 
allows  the  user  to  select  various  parameters,  such  as  the  effective  detection,  classification  and 
identification  ranges  of  the  flash  sensor,  to  tailor  the  system’s  performance  to  emulate  the 
characteristics  of  a  specific  device.  The  decision  on  the  detection/  classification/ 
identification  of  a  projectile  is  made  only  once,  at  the  time  of  launch,  by  the  flash  sensor. 
Other  parameters  that  can  be  specified  for  the  flash  sensor  include  field  of  view  (FOV)  and 
processing  delay  time. 

The  tracking  sensor  module  simulates  a  sensor  that  is  able  to  develop  a  track  of  a 
threat  munition  through  a  portion  of  its  flight.  An  Infrared  search  and  track  sensor  or  a  radar 
sensor  are  examples  of  such  systems.  Similar  to  the  flash  sensor,  the  tracking  sensor  allows 
the  user  to  input  parameters  that  specify  the  performance  of  the  tracking  sensor,  including 
function  ranges,  FOV  and  processing  delays.  The  tracking  sensor  also  includes  parameters  to 
represent  trajectory  estimation  and  hence  infer  an  “1  am  the  target”  determination.  The  track 
determination  is  modeled  using  a  Fuzzy  Logic  function  related  to  the  length  of  time  a  threat 
munition  has  been  tracked.  As  the  tracking  time  exceeds  an  input  threshold,  a  determination 
that  “I  am  the  target”  becomes  more  certain. 

The  third  type  of  sensor  represented  is  a  laser  warning  sensor.  The  laser  sensor 
represents  a  system  that  can  determine  when  a  vehicle  is  illuminated  by  a  laser  rangefinder, 
laser  designator  or  beamrlder  missile  laser  beam.  The  laser  sensor  has  only  one  range 
parameter,  classification  range.  For  this  sensor,  it  is  assumed  that  detection  and 
classification  occur  simultaneously.  Classification  refers  to  a  determination  of  whether  the 
illumination  is  from  a  rangefinder,  designator  or  beamrider.  With  the  laser  sensor,  an  “1  am 
the  target”  determination  is  also  assumed  to  occur  with  classification.  The  laser  sensor  input 
parameters  also  include  FOV  specification. 

2.2  THREAT  RESOLUTION 

The  threat  resolution  module’s  responsibility  is  to  process  the  output  reports  from  the 
sensors  and  determine  the  appropriate  cormtermeasure  response  to  the  sensed  threat.  On 
this  project,  there  was  no  attempt  to  develop  a  sophisticated  threat  resolution  module:  other 
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projects  at  TARDEC  are  pursuing  such  developments.  The  present  software  uses  a  simple 
prioritization  scheme  to  detennlne  countermeasure  reactions.  Only  automatic  counter¬ 
measure  responses  are  simulated  in  MultiSlM-IDS.  The  MultiSlM-lDS  threat  resolution  logic 
follows  the  rules  outlined  below: 

■  No  countermeasures  are  deployed  until  a  classification  and  an  “I  am  the 
target”  determination  is  made  by  one  of  the  sensors. 

■  Only  a  countermeasure  expected  to  be  effective  against  a  particular  threat 
type  is  deployed  against  such  a  threat. 

■  The  countermeasures  are  deployed  in  the  following  priority: 

Missile  Countermeasure  Device  (MCD) 

Laser  Countermeasme  Device 
Active  Countermeasure  System 
Smoke/  Obscurant  System. 

■  The  first  countermeasure  expected  to  be  effective  against  the  current 
incoming  threat  is  used,  unless  otherwise  engaged. 

■  A  countermeasure  is  not  deployed  if  there  is  already  a  countermeasure  in 
effect  that  is  expected  to  counter  that  threat. 

■  A  countermeasure  is  not  deployed  if  the  threat  has  passed  (l.e.,  missed) 
the  defended  vehicle. 

The  fact  that  a  countermeasure  is  deployed  against  a  threat,  does  not  mean  that  a 
countermeasure  will  always  be  effective.  The  countermeasure  effectiveness  is  determined  by 
another  modxile,  based  on  the  time  the  countermeasure  has  to  act  on  the  threat  and  the 
probability  of  effectiveness  of  the  countermeasure. 

2.3  COUNTERME^URES 

At  this  time,  four  types  of  countermeasures  are  represented  in  MultiSIM-lDS: 
smoke/ obscurants,  an  EO  Missile  Countermeasure  Device,  a  Laser  Designator  Decoy  Device, 
and  an  Active  Protection  System.  As  with  the  sensor,  MultiSIM-lDS  does  not  attempt  to  model 
the  physical  details  of  each  countermeasure,  rather  it  attempts  to  represent  the  functional 
performance  of  these  devices.  Additional  representation  details  could  be  added  in  the  future, 
if  it  is  determined  that  they  are  necessary  for  a  particular  exercise  or  experiment. 

2.3.1  SMOKE/OBSCURANT  SYSTEM 

The  smoke/obscurant  countermeasure  system  is  represented  as  screening  the  vehicle 
from  a  defined  sector,  for  a  specified  period  of  tfine.  No  wind  Interaction  is  represented.  The 
parameters  of  the  smoke  system  include  deployment  direction,  smoke  screening  radius, 
distance  to  cloud  center,  smoke  cloud  duration,  and  detonation  delay.  The  radius  is  the 
“radius”  of  the  smoke  cloud  parallel  to  the  ground  and  distance  is  the  distance  of  the  cloud 
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from  the  center  of  the  vehicle.  The  simulation  assumes  that  the  entire  azimuth  sector  defined 
by  the  smoke  cloud  radius  and  distance  is  screened.  The  delay  is  the  length  of  time  after  the 
deployment  command  that  is  required  for  the  smoke  screen  to  become  effective.  The  duration 
is  the  length  of  time  the  screen  remains  effective. 

Multiple  screens  can  be  represented,  and  a  number  of  reloads  can  be  specified.  For 
example,  the  Ml  could  be  reasonably  represented  as  having  two  independent  screens  (left- 
front  and  right-front)  and  two  loads  available  for  each  screen. 

2.3.2  EO  MISSILE  COUNTERMEASURE  DEVICE 

The  EO  Missile  Countermeasure  Device  (MCD)  is  a  countermeasure  effective  against 
certain  EO  command-to-llne-of-sight  guided  missiles.  The  system  requires  a  beam  to  be 
pointed  in  the  direction  of  the  incoming  missile  to  defeat  the  munition.  The  size  of  the  MCD 
FOV  is  defined  by  input  parameters.  The  device  is  effective  if  the  incoming  missile  is  within  its 
FOV  for  a  given  amount  of  time. 

A  slewable  MCD  can  also  be  represented.  Two  additional  parameters  are  used  in  the 
slewable  version  of  the  MCD:  SlewRate,  in  degrees  per  second,  and  AssignmentDuration,  in 
seconds.  The  Slew  Rate  is  the  average  rate  at  which  the  device  can  move  to  point  in  the 
direction  of  an  incoming  threat.  The  device  is  assumed  to  be  able  to  rotate  about  the  z-axis. 
The  Assignment  Duration  is  the  time  that  the  MCD  will  be  pointed  in  the  direction  of  the 
threat  after  slewing.  The  device  will  not  respond  to  a  new  threat  (outside  its  angular  coverage) 
imtll  the  Assignment  Duration  for  the  present  usage  has  passed. 

2.3.3  LASER  COUNTERMEASURE  DEVICE 

A  Laser  Countermeasure  Device  (LCD)  is  any  countermeasure  effective  against  a  laser 
guided  munition.  Its  main  purpose  is  to  represent  a  laser  repeater  or  decoy  device  that 
flluminates  a  nearby  terrain  patch  and  thus  causes  a  laser-designator  guided  missile  to  hit  the 
illuminated  terrain  rather  than  the  defended  vehicle.  The  LCD  device  parameters  are  similar 
to  the  parameters  for  the  MCD  system.  The  LCD  can  also  be  a  slewable  device. 

2.3.4  ACTIVE  PROTECTION  SYSTEM 

An  Active  Protection  System  (APS)  describes  a  countermeasure  device  that  physically 
interferes  with  the  functioning  of  an  incoming  munition.  Typical  APS  systems  utilize 
“shotgun”  pellets  or  a  guided  projectile  to  intercept  an  incoming  round.  The  simulation  for 
this  device  contains  the  following  parameters:  SlewRate,  FhghtDuration,  NumberofGrenades 
and  AverageEffectiveness. 
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2.4  COUNTERMEASURE  EFFECTIVENESS  DETERMINATION 

The  nature  of  DIS  allows  an  retroactive  determination  of  countermeasure  effectiveness 
by  the  IDS  simulation.  AVhen  a  Detonation  PDU  is  received  Indicating  a  (potential)  munition 
impact  on  a  defended  vehicle,  a  determination  is  made  if  a  countermeasure  has  been  deployed 
against  that  munition  and  if  that  countermeasure  was  effective.  Cormtermeasure  effectiveness 
is  determined  using  the  following  rules.  First,  certain  types  of  countermeasures  are  only 
effective  against  certain  types  of  munitions.  MCD  and  LCD  countermeasures  are  only  effective 
against  EO  guided  and  laser  guided  missiles,  respectively.  Smoke/ obscurants  are  considered 
effective  against  all  types  of  missiles.  The  APS  system  is  effective  against  either  missiles  or 
main  gxm  rounds.  No  countermeasures  except  an  APS  system  is  effective  against  main-gun 
rounds. 

Given  the  matching  threat  type,  the  effectiveness  determinations  for  the  MCD,  LCD  and 
smoke/obscurant  countermeasures  are  similar:  if  the  countermeasure  has  been  effectively 
deployed  against  the  munition  for  a  given  time-duration  (an  input  typically  set  as  2-3 
seconds),  then  the  countermeasure  is  determined  to  be  effective.  The  APS  system  is  assumed 
to  be  effective,  with  a  given  probability.  If  it  has  been  effectively  deployed  against  the  munition. 

Countermeasures  will  not  always  be  effective  for  many  realistic  reasons.  If  a  slewing 
countermeasure  (MCD  or  LCD)  is  engaging  one  threat,  it  wUl  not  be  available  to  defend  a 
threat  from  a  different  direction.  Close-In  or  high-speed  missiles  may  not  be  defeated  because 
there  is  not  time  for  the  countermeasure  to  deploy.  Smoke/ obscurant  countermeasures 
require  a  finite  time  to  become  effective.  The  APS  system  is  modeled  as  effective  for  only  a 
certain  percentage  of  engagements.  Both  smoke/obscurant  and  APS  systems  are  limited  by 
the  number  of  reloads  available.  Finally,  the  IDS  system  wUl  only  be  effective  against  threats 
which  are  defined  as  defensible  in  its  “Defensible  Munitions”  input  fUe. 
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3.0  MultiSIM-mS  SOFTWARE  IMPLEMENTATION 


3.1  SIMULATION  ARCHITECTURE 

A  simplified  version  of  the  software  architecture  of  MultlSIM-IDS  is  illustrated  in 
Figures.  Each  box  in  that  figure  represents  a  separate  C++  module  (object).  Most 
connections  between  the  various  modules  are  also  shoAvn  on  the  figure.  This  structure 
enforces  the  main  tenants  of  object-oriented  design:  localization  of  functions  within  class 
objects  and  well-defined  interfaces  between  objects  of  different  classes. 

The  data  transfer  between  modules  is  made  via  software  ports  that  are  actually 
connected  at  execution  time  based  on  the  instructions  in  a  “Connections  File.”  This  is  a  very 
flexible  mechanism  that  allows  configuration  of  various  IDS  systems  using  the  same  software 
components. 

The  Simulation  Manager  Module  initiates  the  simulation  and  generates  internal  timing 
Information  that  is  used  by  most  modules  of  MultiSlM-lDS.  A  main  function  of  the  Simulation 
Manager  is  to  “connect”  the  various  IDS  modules  using  the  Information  contained  in  the 
Connections  File.  It  also  provides  for  the  initialization  of  the  parameters  of  the  various 
modules  via  the  “.Inlt”  initialization  files.  The  commercial  VR-Link  software  runs  in  the 
background  and  provides  access  to  the  DIS  network  connection,  monitoring  entity  state  PDU’s 
and  dead  reckoning  to  the  entity  locations. 

The  main  MultiSIM-IDS  software  components  are  triggered  by  PDU’s  received  over  the 
DIS  network,  plus  internal  timing  events.  The  cycle  is  started  when  a  Fire  or 
Laser/Designator  PDU  is  received.  The  PDU  notification  is  converted  to  an  OMI  (internal) 
event  by  the  Converter  module  and  passed  either  to  the  Designator  E>ent  Manager  (for 
Laser/Designator  PDU’s)  or  the  Movement  E^ent  Manager  (for  Fire  PDU’s).  The  event 
managers  create  designator  or  movement  events  at  defined  Intervals  (typically  0. 1  seconds) 
that  drive  the  sensor  and  countermeasure  modules.  At  each  event  tick,  each  sensor  is  polled 
to  determine  if  it  can  see  the  threat  (or  laser).  If  so,  it  creates  or  updates  a  track  file  on  each 
threat.  Also,  at  each  tick,  the  Threat  Resolution  Module  reviews  the  threat  files  to  determine  if 
it  has  enough  information  to  attempt  to  deploy  a  countermeasure  against  that  threat.  If  a 
countermeasure  action  is  appropriate,  the  Threat  Resolution  Module  poUs  the 
countermeasures  to  determine  if  any  are  already  deployed  that  should  be  effective  against  that 
threat,  and  if  any  are  available  for  deployment.  If  an  appropriate  countermeasure  is  available, 
the  Threat  Resolution  Module  wlU  teU  a  Countermeasure  System  to  deploy  it.  The  Threat 
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Figure  3.  MultiSIM-IDS  Software  Architecture. 


Resolution  Module  also  causes  the  Issuance  of  status  messages,  via  Data  PDU’s,  that  notify 
other  network  entities  (e.g.,  Applique  Simulation)  of  the  detection  of  threats  or  the  deployment 
of  countermeasures. 

A  second  cycle  is  driven  by  receipt  of  a  Detonation  PDU.  If  a  Detonation  PDU  is 
received  that  indicates  the  Defended  Vehicle  would  have  been  hit  by  a  munition  (in  the 
absence  of  countermeasures),  that  triggers  a  determination  by  MultiSIM-IDS  of  the 
effectiveness  of  any  countermeasures  deployed  against  that  munition.  That  determination  is 
performed  by  the  Countermeasure  Adjudicator  Module.  The  Countermeasure  Adjudicator 
Module  monitors  at  each  movement  event  time  step  which,  if  any,  countermeasures  are 
effective  against  each  munition.  When  triggered  by  the  Detonation  event,  the  Countermeasure 
Adjudicator  Module  determines  the  total  time  countermeasures  were  effective  against  that 
munition,  and  if  that  time  is  greater  than  an  input  threshold  parameter,  it  emits  a  new 
Detonation  PDU.  If  the  countermeasure  was  determined  to  be  effective,  the  new  Detonation 
PDU  indicates  a  munition  miss.  If  the  countermeasures  were  determined  not  to  be  effective, 
the  new  Detonation  PDU  indicates  a  hit,  as  in  the  original  Detonation  PDU. 

3.2  INTEGRATION  WITH  MANNED  SIMULATORS  AND  MODSAF  ENTITIES 

3.2. 1  INTEGRATION  WITH  MANNED  SIMULATORS  AND  MODSAF  ENTITIES 

MultiSIM-IDS  adds  simulation  of  an  Integrated  Defense  System  to  existing  DIS 
manned  vehicle  simulators  or  semi-automated  forces.  The  main  function  of  an  IDS  system  is 
to  prevent  the  defended  vehicle  from  being  hit/ killed  by  incoming  munitions.  To  accomplish 
that  in  simulation,  MultiSIM-IDS  evaluates  Detonation  PDU’s  issued  by  the  threat  simiilators, 
before  they  are  processed  by  the  defended  vehicle.  If  the  munition  is  determined  to  have 
missed  as  a  result  of  the  simulated  IDS  system,  a  grormd  Impact  Detonation  PDU  is  issued.  If 
the  IDS  system  was  unsuccessful  in  defeating  the  incoming  munition,  a  validated  version  of 
the  original  Detonation  PDU,  Indicating  defended  vehicle  Impact,  is  issued.  For  this  scheme  to 
work,  one  change  needs  to  be  made  to  the  manned  simulator  or  ModSAF  software:  their 
damage  tables  need  to  be  modified  so  that  only  validated  Detonation  PDU’s  are  processed. 
Detonation  PDU’s  are  validated  by  setting  munition  ID’s  “Special”  field  to  “1”.  The  user  must 
change  the  damage  tables  for  the  defended  vehicles  so  that  only  Detonation  PDU’s  with  the 
Special  field  set  to  1  cause  damage. 
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3.2.2  INTEGRATION  LESSONS  LEARNED  WITH  RESPECT  TO  INTERFACE  TO 
MODSAF 

In  the  course  of  the  code  development,  we  encountered  a  number  of  problems  where 
ModSAF-generated  PDU’s  or  data  did  not  conform  to  DIS  standards  or  otherwise  caused 
problems  with  our  simulation.  ModSAF  problems  encountered  included: 

■  The  Munition  (entity)  ID  was  omitted  from  the  Fire  PDU’s  issued  by 
ModSAF. 

■  An  Entity  Creation  PDU  was  not  issued  for  the  newly  created  entity  (the 
missile). 

■  The  velocity  vector  given  in  the  Fire  PDU  for  a  main  gun  round  did  not  atm 
the  round  directly  at  the  target,  but  causes  it  to  fly  under  the  target. 

■  When  a  laser  rangefinder  Ulmninated  the  target,  a  Designator  PDU  was 
issued,  but  many  of  the  PDU  fields  (for  example  power  and  wavelength) 
that  should  be  set  were  not,  and  hence  defaulted  to  "zero." 

■  A  laser  designator  illumination  causes  a  string  of  PDU  to  be  Issued,  but 
with  no  Indication  of  the  last  PDU  in  the  sequence. 

Each  of  the  above  seems  a  small  item,  however,  because  they  were  unexpectedly 
encountered  in  debugging  our  software,  and  most  necessitated  a  “work-around,”  they 
significantly  added  to  our  development  effort.  Some  of  the  problems  may  have  been  corrected 
in  the  latest  versions  of  ModSAF,  but  because  ModSAF  is  so  widely  used  in  DIS  exercises,  it  is 
imperative  that  it  strictly  conform  to  the  DIS  protocols. 

3.3  APPLICATIONS  AND  BATTLE  LAB  TEST  AND  EVALUATION 

3.3.1  APPLICATION  IN  THE  FPE-HI  EXPERIMENT 

An  initial  version  of  MultiSIM-IDS  was  used  as  a  component  of  the  Force  Protection 
Experiment  in,  perforaied  by  the  Mounted  Maneuver  Battle  Lab.  The  FPE-III  experiment  was 
performed  at  the  Mounted  Warfare  Test-Bed  (MWTB)  during  the  fall  of  1996.  The 
configuration  of  MultiSIM-IDS  as  used  in  FPE-III  is  illustrated  in  Figure  4.  In  that  experiment, 
MultiSIM-IDS  simulated  an  IDS  system  consisting  of  a  mlssUe  warning  receiver,  an  EO  missile 
countermeasure  device  and  smoke/obscurant  countermeasures.  The  simulation  was  used  to 
“defend”  four  manned  simulators  and  ten  ModSAF  vehicles.  In  addition  to  the  IDS  system, 
FPE-III  Included  simidations  of  a  developmental  combat  identification  system,  E-BCIS,  and  a 
battlefield  situational  awareness  display.  Applique. 

In  FPE-III,  the  IDS  simulation  provided  audio  warning  of  incoming  rounds  and 
countermeasure  defense  against  threat  missiles.  IDS  warnings  of  missile  launches  and  main 
gun  firings  were  shared  among  the  crews  of  the  manned  simulators  via  feeds  to  the  situational 
awareness  displays  provided  by  Applique.  The  interfaces  between  the  IDS  simulation,  a  PC 
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that  provided  manned  simulator  audio,  and  Applique  were  provided  by  the  MWTB  contractor, 
Lockheed-Martin,  and  its  subcontractor,  SAIC. 


Figure  4.  MultiSlM-IDS  DIS  simulation  usage  in  FPE-lII. 

The  formal  analysis  of  the  experiment  is  not  yet  available:  however,  the  IDS  simulation 
operated  with  no  problems  throughout  the  six-week  experiment.  There  also  were  lessons 
learned  in  the  setup  and  initial  configuration  of  the  experiment.  One  issue  addressed  In 
generation  of  the  audio  warnings  was  that  the  data  needs  to  be  filtered  before  presentation  to 
the  crew.  The  IDS  system  is  able  to  generate  multiple  reports  as  a  single  missile  is  first 
detected,  is  classified,  is  determined  to  be  aimed  at  a  particular  vehicle,  is  countermeasured, 
etc.  The  crew  is  not  able  or  Interested  in  that  wealth  of  information;  a  single  warning  that  an 
incoming  munition  has  been  detected  and  the  angle  of  the  incoming  roimd  is  sufficient 
Information  for  the  crew.  A  second  issue  addressed  was  that  Applique’s  formats  do  not 
support  display  of  a  simple  Une-of-bearing  (LOB)  report,  to  indicate  incoming  missile  direction. 
Because  of  that  limitation,  IDS  LOB  reports  had  to  be  approximated  as  spot  reports  for 
Applique,  with  an  assumed  range  of  2.5  kilometers  from  the  defended  vehicle. 

With  the  above  issues  addressed,  the  IDS  simulation  functioned  well  throughout  the 
FPE-111  experiment.  The  soldier  crews  were  pleased  with  the  Information  obtained  via  the  IDS 
system  and  expressed  disappointment  when  the  IDS  system  was  not  used  in  a  particular  trial. 
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3.3.2  MultiSIM-mS  SOFTWARE  TEST  AND  EVALUATION 


The  complete  MultiSIM-IDS  simulation  is  schedviled  for  a  formal  Test  and  Evaluation 
by  TECO  at  the  Mounted  Warfare  Test  Bed  at  Ft.  Knox  during  February  1997.  The  results  of 
that  testing  are  not  yet  available.  Internal  testing  at  OptiMetrics  facilities  during  January 
1997  indicates  that  aU  modules  are  functioning  correctly.  Preliminary  testing  of  a  limited 
capability  version  of  MultiSlM-lDS  was  performed  at  the  Battle  Lab  prior  to  the  FPE-llI 
experiments.  The  IDS  simulation  performed  correctly  during  those  tests. 
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4.0  SUMMARY  AND  RECOMMENDATIONS 


4.1  PRO  JECT  SUMMARY 

The  MultiSIM-IDS  simulation  has  been  successfully  developed,  tested,  utilized  In  a 
Battle  Lab  experiment,  and  delivered  to  TARDEC  and  the  Mounted  Maneuver  Battle  Lab. 
MultiSlM-IDS  provides  a  very  flexible  capability  to  simulate  a  variety  of  sensors  and 
countermeasures  as  components  of  the  IDS  systems,  within  a  DIS  simulation  environment. 
The  design  of  the  IDS  simulation  allows  the  user  to  configure  the  software  to  simulate  various 
IDS  systems  and  to  set  parameters  that  govern  the  operation  of  the  individual  sensors  and 
countermeasures.  MultiSIM-IDS  provides  a  flexible  tool  for  future  Battle  Lab  experiments. 

4.2  RECOMMENDATIONS  FOR  FUTURE  MultiSIM-IDS  DEVELOPMENTS  AND 

APPLICATIONS 

A  proposed  project  would  extend  the  MultiSIM-IDS  system  to  allow  the  simulation  of 
Distributed  Integrated  Defense  Systems.  A  Distributed-IDS  system  would  spread  the  IDS 
components  over  a  number  of  platforms  (e.g.,  the  vehicles  in  a  platoon)  and  link  them  together 
via  communications  network.  Potentially,  that  could  make  IDS  systems  more  affordable, 
because  expensive  sensors  and  countermeasures  would  not  have  to  be  duplicated  for  every 
vehicle  in  the  force. 

MultiSIM-IDS  also  provides  a  platform  for  detailed  simulation  of  the  components  of  IDS 
systems,  or  Indeed  many  types  of  sensor  systems.  Higher  fidelity  models  of  sensors, 
countermeasures  or  the  threat  resolution  logic  could  easily  be  added  to  the  current 
simulation.  The  current  version  of  the  simulation  uses  automatic  deployment  logic  for  the 
countermeasures.  An  extension  of  the  simulation  could  allow  for  display  of  warnings  to  the 
crew  and  semi-automatic  (crew-managed)  deployment  of  countermeasures. 

As  the  simulation  currently  exists,  it  could  be  directly  used  in  tradeoff  experiments  at 
the  MWTB  to  determine  an  optlmxim  suite  of  sensors  and  countermeasures  for  a  particular 
vehicle  application.  Because  the  MultiSIM-IDS  simulation  works  equally  well  with  ModSAF 
entitles  as  with  manned  simulators,  tradeoff  studies  could  also  be  run  using  ModSAF  as  a 
DIS-based  constructive  simulation.  Finally,  because  the  DoD  is  transitioning  to  a  standard 
High  Level  Architecture  (HLA)  from  its  current  DIS  simulation  standard,  MultlSIM-IDS  wUl 
need  to  be  made  HLA  compliant.  HLA  compliance  requires  Incorporation  of  a  Real-Time 
Interface  (RTl)  and  definition  of  the  simulations  Interface  components  In  a  Simulation  Object 
Model  (SOM). 
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